Configuration reference

Basic parameters

• background
• custom_proc_title
• listen
• memtx_dir
• pid_file
• read_only
• sql_cache_size
• vinyl_dir
• vinyl_timeout
• username
• wal_dir
• work_dir
• worker_pool_threads
• strip_core
• memtx_use_mvcc_engine

background¶

Since version 1.6.2. Run the server as a background task. The log and pid_file parameters must be non-null for this to work.

Type: boolean

Default: false

Environment variable: TT_BACKGROUND

Dynamic: no

custom_proc_title¶

Since version 1.6.7. Add the given string to the server’s process title (what’s shown in the COMMAND column for ps -ef and top -c commands).

For example, ordinarily ps -ef shows the Tarantool server process thus:

$ ps -ef | grep tarantool
1000     14939 14188  1 10:53 pts/2    00:00:13 tarantool <running>

But if the configuration parameters include custom_proc_title='sessions' then the output looks like:

$ ps -ef | grep tarantool
1000     14939 14188  1 10:53 pts/2    00:00:16 tarantool <running>: sessions

Type: string

Default: null

Environment variable: TT_CUSTOM_PROC_TITLE

Dynamic: yes

listen¶

Since version 1.6.4.

The read/write data port number or URI (Universal Resource Identifier) string. Has no default value, so must be specified if connections occur from the remote clients that don’t use the “admin port”. Connections made with listen = URI are called “binary port” or “binary protocol” connections.

A typical value is 3301.

box.cfg { listen = 3301 }

box.cfg { listen = "127.0.0.1:3301" }

Note

A replica also binds to this port, and accepts connections, but these connections can only serve reads until the replica becomes a master.

Starting from version 2.10.0, you can specify several URIs, and the port number is always stored as an integer value.

Type: integer or string

Default: null

Environment variable: TT_LISTEN

Dynamic: yes

memtx_dir¶

Since version 1.7.4. A directory where memtx stores snapshot (.snap) files. Can be relative to work_dir. If not specified, defaults to work_dir. See also wal_dir.

Type: string

Default: “.”

Environment variable: TT_MEMTX_DIR

Dynamic: no

pid_file¶

Since version 1.4.9. Store the process id in this file. Can be relative to work_dir. A typical value is “tarantool.pid”.

Type: string

Default: null

Environment variable: TT_PID_FILE

Dynamic: no

read_only¶

Since version 1.7.1. Say box.cfg{read_only=true...} to put the server instance in read-only mode. After this, any requests that try to change persistent data will fail with error ER_READONLY. Read-only mode should be used for master-replica replication. Read-only mode does not affect data-change requests for spaces defined as temporary. Although read-only mode prevents the server from writing to the WAL, it does not prevent writing diagnostics with the log module.

Type: boolean

Default: false

Environment variable: TT_READ_ONLY

Dynamic: yes

Setting read_only == true affects spaces differently depending on the options that were used during box.schema.space.create, as summarized by this chart:

Option	Can be created?	Can be written to?	Is replicated?	Is persistent?
(default)	no	no	yes	yes
temporary	no	yes	no	no
is_local	no	yes	no	yes

sql_cache_size¶

Since version 2.3.1. The maximum number of bytes in the cache for SQL prepared statements. (The number of bytes that are actually used can be seen with box.info.sql().cache.size.)

Type: number

Default: 5242880

Environment variable: TT_SQL_CACHE_SIZE

Dynamic: yes

vinyl_dir¶

Since version 1.7.1. A directory where vinyl files or subdirectories will be stored. Can be relative to work_dir. If not specified, defaults to work_dir.

Type: string

Default: “.”

Environment variable: TT_VINYL_DIR

Dynamic: no

vinyl_timeout¶

Since version 1.7.5. The vinyl storage engine has a scheduler which does compaction. When vinyl is low on available memory, the compaction scheduler may be unable to keep up with incoming update requests. In that situation, queries may time out after vinyl_timeout seconds. This should rarely occur, since normally vinyl would throttle inserts when it is running low on compaction bandwidth. Compaction can also be ordered manually with index_object:compact().

Type: float

Default: 60

Environment variable: TT_VINYL_TIMEOUT

Dynamic: yes

username¶

Since version 1.4.9. UNIX user name to switch to after start.

Type: string

Default: null

Environment variable: TT_USERNAME

Dynamic: no

wal_dir¶

Since version 1.6.2. A directory where write-ahead log (.xlog) files are stored. Can be relative to work_dir. Sometimes wal_dir and memtx_dir are specified with different values, so that write-ahead log files and snapshot files can be stored on different disks. If not specified, defaults to work_dir.

Type: string

Default: “.”

Environment variable: TT_WAL_DIR

Dynamic: no

work_dir¶

Since version 1.4.9. A directory where database working files will be stored. The server instance switches to work_dir with chdir(2) after start. Can be relative to the current directory. If not specified, defaults to the current directory. Other directory parameters may be relative to work_dir, for example:

box.cfg{
    work_dir = '/home/user/A',
    wal_dir = 'B',
    memtx_dir = 'C'
}

will put xlog files in /home/user/A/B, snapshot files in /home/user/A/C, and all other files or subdirectories in /home/user/A.

Type: string

Default: null

Environment variable: TT_WORK_DIR

Dynamic: no

worker_pool_threads¶

Since version 1.7.5. The maximum number of threads to use during execution of certain internal processes (currently socket.getaddrinfo() and coio_call()).

Type: integer

Default: 4

Environment variable: TT_WORKER_POOL_THREADS

Dynamic: yes

strip_core¶

Since version 2.2.2. Whether coredump files should include memory allocated for tuples. (This can be large if Tarantool runs under heavy load.) Setting to true means “do not include”. In an older version of Tarantool the default value of this parameter was false.

Type: boolean

Default: true

Environment variable: TT_STRIP_CORE

Dynamic: no

memtx_use_mvcc_engine¶

Since version 2.6.1. Enables transactional manager if set to true.

Type: boolean

Default: false

Environment variable: TT_MEMTX_USE_MVCC_ENGINE

Dynamic: no

Configuring the storage

• memtx_memory
• memtx_max_tuple_size
• memtx_min_tuple_size
• memtx_allocator
• slab_alloc_factor
• slab_alloc_granularity
• vinyl_bloom_fpr
• vinyl_cache
• vinyl_max_tuple_size
• vinyl_memory
• vinyl_page_size
• vinyl_range_size
• vinyl_run_count_per_level
• vinyl_run_size_ratio
• vinyl_read_threads
• vinyl_write_threads

memtx_memory¶

Since version 1.7.4. How much memory Tarantool allocates to actually store tuples. When the limit is reached, INSERT or UPDATE requests begin failing with error ER_MEMORY_ISSUE. The server does not go beyond the memtx_memory limit to allocate tuples, but there is additional memory used to store indexes and connection information. Depending on actual configuration and workload, Tarantool can consume up to 20% more than the memtx_memory limit.

Type: float

Default: 256 * 1024 * 1024 = 268435456 bytes

Minimum: 33554432 bytes (32 MB)

Environment variable: TT_MEMTX_MEMORY

Dynamic: yes but it cannot be decreased

memtx_max_tuple_size¶

Since version 1.7.4. Size of the largest allocation unit, for the memtx storage engine. It can be increased if it is necessary to store large tuples. See also: vinyl_max_tuple_size.

Type: integer

Default: 1024 * 1024 = 1048576 bytes

Environment variable: TT_MEMTX_MAX_TUPLE_SIZE

Dynamic: yes

memtx_min_tuple_size¶

Since version 1.7.4. Size of the smallest allocation unit. It can be decreased if most of the tuples are very small. The value must be between 8 and 1048280 inclusive.

Type: integer

Default: 16 bytes

Environment variable: TT_MEMTX_MIN_TUPLE_SIZE

Dynamic: no

memtx_allocator¶

Since version 2.10.0. Specifies the allocator used for memtx tuples. The possible values are system and small:

• system is based on the malloc function. This allocator allocates memory as needed, checking that the quota is not exceeded.
• small is a special slab allocator. Note that this allocator is prone to unresolvable fragmentation on specific workloads, so you can switch to system in such cases.

Type: string

Default: ‘small’

Environment variable: TT_MEMTX_ALLOCATOR

Dynamic: No

slab_alloc_factor¶

The multiplier for computing the sizes of memory chunks that tuples are stored in. A lower value may result in less wasted memory depending on the total amount of memory available and the distribution of item sizes. Allowed values range from 1 to 2.

See also: slab_alloc_granularity

Type: float

Default: 1.05

Environment variable: TT_SLAB_ALLOC_FACTOR

Dynamic: no

slab_alloc_granularity¶

Since version 2.8.1. Specifies the granularity (in bytes) of memory allocation in the small allocator. The value of slab_alloc_granularity should be a power of two and should be greater than or equal to 4. Below are few recommendations on how to adjust the slab_alloc_granularity value:

• To store small tuples of approximately the same size, set slab_alloc_granularity to 4 bytes to save memory.
• To store tuples of different sizes, you can increase the slab_alloc_granularity value. This results in allocating tuples from the same mempool.

See also: slab_alloc_factor

Type: number

Default: 8 bytes

Environment variable: TT_SLAB_ALLOC_GRANULARITY

Dynamic: no

vinyl_bloom_fpr¶

Since version 1.7.4. Bloom filter false positive rate – the suitable probability of the bloom filter to give a wrong result. The vinyl_bloom_fpr setting is a default value for one of the options in the Options for space_object:create_index() chart.

Type: float

Default: 0.05

Environment variable: TT_VINYL_BLOOM_FPR

Dynamic: no

vinyl_cache¶

Since version 1.7.4. The cache size for the vinyl storage engine. The cache can be resized dynamically.

Type: integer

Default: 128 * 1024 * 1024 = 134217728 bytes

Environment variable: TT_VINYL_CACHE

Dynamic: yes

vinyl_max_tuple_size¶

Since version 1.7.5. Size of the largest allocation unit, for the vinyl storage engine. It can be increased if it is necessary to store large tuples. See also: memtx_max_tuple_size.

Type: integer

Default: 1024 * 1024 = 1048576 bytes

Environment variable: TT_VINYL_MAX_TUPLE_SIZE

Dynamic: no

vinyl_memory¶

Since version 1.7.4. The maximum number of in-memory bytes that vinyl uses.

Type: integer

Default: 128 * 1024 * 1024 = 134217728 bytes

Environment variable: TT_VINYL_MEMORY

Dynamic: yes but it cannot be decreased

vinyl_page_size¶

Since version 1.7.4. Page size. Page is a read/write unit for vinyl disk operations. The vinyl_page_size setting is a default value for one of the options in the Options for space_object:create_index() chart.

Type: integer

Default: 8 * 1024 = 8192 bytes

Environment variable: TT_VINYL_PAGE_SIZE

Dynamic: no

vinyl_range_size¶

Since version 1.7.4. The default maximum range size for a vinyl index, in bytes. The maximum range size affects the decision whether to split a range.

If vinyl_range_size is not nil and not 0, then it is used as the default value for the range_size option in the Options for space_object:create_index() chart.

If vinyl_range_size is nil or 0, and range_size is not specified when the index is created, then Tarantool sets a value later depending on performance considerations. To see the actual value, use index_object:stat().range_size.

In Tarantool versions prior to 1.10.2, vinyl_range_size default value was 1073741824.

Type: integer

Default: nil

Environment variable: TT_VINYL_RANGE_SIZE

Dynamic: no

vinyl_run_count_per_level¶

Since version 1.7.4. The maximal number of runs per level in vinyl LSM tree. If this number is exceeded, a new level is created. The vinyl_run_count_per_level setting is a default value for one of the options in the Options for space_object:create_index() chart.

Type: integer

Default: 2

Environment variable: TT_VINYL_RUN_COUNT_PER_LEVEL

Dynamic: no

vinyl_run_size_ratio¶

Since version 1.7.4. Ratio between the sizes of different levels in the LSM tree. The vinyl_run_size_ratio setting is a default value for one of the options in the Options for space_object:create_index() chart.

Type: float

Default: 3.5

Environment variable: TT_VINYL_RUN_SIZE_RATIO

Dynamic: no

vinyl_read_threads¶

Since version 1.7.5. The maximum number of read threads that vinyl can use for some concurrent operations, such as I/O and compression.

Type: integer

Default: 1

Environment variable: TT_VINYL_READ_THREADS

Dynamic: no

vinyl_write_threads¶

Since version 1.7.5. The maximum number of write threads that vinyl can use for some concurrent operations, such as I/O and compression.

Type: integer

Default: 4

Environment variable: TT_VINYL_WRITE_THREADS

Dynamic: no

Checkpoint daemon

• checkpoint_count
• checkpoint_interval
• checkpoint_wal_threshold

The checkpoint daemon is a fiber which is constantly running. At intervals, it may make new snapshot (.snap) files and then may delete old snapshot files.

The checkpoint_interval and checkpoint_count configuration settings determine how long the intervals are, and how many snapshots should exist before deletions occur.

Tarantool garbage collector

The checkpoint daemon may activate the Tarantool garbage collector which deletes old files. This garbage collector is distinct from the Lua garbage collector which is for Lua objects, and distinct from a Tarantool garbage collector which specializes in handling shard buckets.

If the checkpoint daemon deletes an old snapshot file, then the Tarantool garbage collector will also delete any write-ahead log (.xlog) files which are older than the snapshot file and which contain information that is present in the snapshot file. It will also delete obsolete vinyl .run files.

The checkpoint daemon and the Tarantool garbage collector will not delete a file if:

• a backup is ongoing and the file has not been backed up (see “Hot backup”), or
• replication is ongoing and the file has not been relayed to a replica (see “Replication architecture”),
• a replica is connecting, or
• a replica has fallen behind. The progress of each replica is tracked; if a replica’s position is far from being up to date, then the server stops to give it a chance to catch up. If an administrator concludes that a replica is permanently down, then the correct procedure is to restart the server, or (preferably) remove the replica from the cluster.

checkpoint_interval¶

Since version 1.7.4. The interval between actions by the checkpoint daemon, in seconds. If checkpoint_interval is set to a value greater than zero, and there is activity which causes change to a database, then the checkpoint daemon will call box.snapshot() every checkpoint_interval seconds, creating a new snapshot file each time. If checkpoint_interval is set to zero, then the checkpoint daemon is disabled.

For example:

box.cfg{checkpoint_interval=60}

will cause the checkpoint daemon to create a new database snapshot once per minute, if there is activity.

Type: integer

Default: 3600 (one hour)

Environment variable: TT_CHECKPOINT_INTERVAL

Dynamic: yes

checkpoint_count¶

Since version 1.7.4. The maximum number of snapshots that may exist on the memtx_dir directory before the checkpoint daemon will delete old snapshots. If checkpoint_count equals zero, then the checkpoint daemon does not delete old snapshots. For example:

box.cfg{
    checkpoint_interval = 3600,
    checkpoint_count  = 10
}

will cause the checkpoint daemon to create a new snapshot each hour until it has created ten snapshots. After that, it will delete the oldest snapshot (and any associated write-ahead-log files) after creating a new one.

Remember that, as noted earlier, snapshots will not be deleted if replication is ongoing and the file has not been relayed to a replica. Therefore checkpoint_count has no effect unless all replicas are alive.

Type: integer

Default: 2

Environment variable: TT_CHECKPOINT_COUNT

Dynamic: yes

checkpoint_wal_threshold¶

Since version 2.1.2. The threshold for the total size in bytes of all WAL files created since the last checkpoint. Once the configured threshold is exceeded, the WAL thread notifies the checkpoint daemon that it must make a new checkpoint and delete old WAL files.

This parameter enables administrators to handle a problem that could occur with calculating how much disk space to allocate for a partition containing WAL files.

For example, suppose checkpoint_interval = 2 and checkpoint_count = 5 and the average amount that Tarantool writes between each checkpoint interval = 1 GB. Then one could calculate that the necessary amount is (2*5*1) 10GB. But this calculation would be wrong if, instead of writing 1 GB during one checkpoint interval, Tarantool encounters an unusual spike and tries to write 11 GB, causing an operating-system ENOSPC (“no space”) error. By setting checkpoint_wal_threshold to a lower value, say 9 GB, an administrator could prevent the error.

Type: integer

Default: 10^18 (a large number so in effect there is no limit by default)

Environment variable: TT_CHECKPOINT_WAL_THRESHOLD

Dynamic: yes

Binary logging and snapshots

• force_recovery
• wal_max_size
• snap_io_rate_limit
• wal_mode
• wal_dir_rescan_delay
• wal_queue_max_size
• wal_cleanup_delay

force_recovery¶

Since version 1.7.4. If force_recovery equals true, Tarantool tries to continue if there is an error while reading a snapshot file (at server instance start) or a write-ahead log file (at server instance start or when applying an update at a replica): skips invalid records, reads as much data as possible and lets the process finish with a warning. Users can prevent the error from recurring by writing to the database and executing box.snapshot().

Otherwise, Tarantool aborts recovery if there is an error while reading.

Type: boolean

Default: false

Environment variable: TT_FORCE_RECOVERY

Dynamic: no

wal_max_size¶

Since version 1.7.4. The maximum number of bytes in a single write-ahead log file. When a request would cause an .xlog file to become larger than wal_max_size, Tarantool creates another WAL file.

Type: integer

Default: 268435456 (256 * 1024 * 1024) bytes

Environment variable: TT_WAL_MAX_SIZE

Dynamic: no

snap_io_rate_limit¶

Since version 1.4.9. Reduce the throttling effect of box.snapshot() on INSERT/UPDATE/DELETE performance by setting a limit on how many megabytes per second it can write to disk. The same can be achieved by splitting wal_dir and memtx_dir locations and moving snapshots to a separate disk. The limit also affects what box.stat.vinyl().regulator may show for the write rate of dumps to .run and .index files.

Type: float

Default: null

Environment variable: TT_SNAP_IO_RATE_LIMIT

Dynamic: yes

wal_mode¶

Since version 1.6.2. Specify fiber-WAL-disk synchronization mode as:

• none: write-ahead log is not maintained. A node with wal_mode = none can’t be replication master;
• write: fibers wait for their data to be written to the write-ahead log (no fsync(2));
• fsync: fibers wait for their data, fsync(2) follows each write(2);

Type: string

Default: “write”

Environment variable: TT_WAL_MODE

Dynamic: no

wal_dir_rescan_delay¶

Since version 1.6.2. Number of seconds between periodic scans of the write-ahead-log file directory, when checking for changes to write-ahead-log files for the sake of replication or hot standby.

Type: float

Default: 2

Environment variable: TT_WAL_DIR_RESCAN_DELAY

Dynamic: no

wal_queue_max_size¶

Since version 2.8.1. The size of the queue (in bytes) used by a replica to submit new transactions to a write-ahead log (WAL). This option helps limit the rate at which a replica submits transactions to the WAL. Limiting the queue size might be useful when a replica is trying to sync with a master and reads new transactions faster than writing them to the WAL.

Note

You might consider increasing the wal_queue_max_size value in case of large tuples (approximately one megabyte or larger).

Type: number

Default: 16777216 bytes

Environment variable: TT_WAL_QUEUE_MAX_SIZE

Dynamic: yes

wal_cleanup_delay¶

Since version 2.6.3. The delay (in seconds) used to prevent the Tarantool garbage collector from immediately removing write-ahead log files after a node restart. This delay eliminates possible erroneous situations when the master deletes WALs needed by replicas after restart. As a consequence, replicas sync with the master faster after its restart and don’t need to download all the data again.

Once all the nodes in the replica set are up and running, automatic cleanup is started again even if wal_cleanup_delay has not expired.

Note

The wal_cleanup_delay option has no effect on nodes running as anonymous replicas.

Type: number

Default: 14400 seconds

Environment variable: TT_WAL_CLEANUP_DELAY

Dynamic: yes

Hot standby

hot_standby¶

Since version 1.7.4. Whether to start the server in hot standby mode.

Hot standby is a feature which provides a simple form of failover without replication.

The expectation is that there will be two instances of the server using the same configuration. The first one to start will be the “primary” instance. The second one to start will be the “standby” instance.

To initiate the standby instance, start a second instance of the Tarantool server on the same computer with the same box.cfg configuration settings – including the same directories and same non-null URIs – and with the additional configuration setting hot_standby = true. Expect to see a notification ending with the words I> Entering hot standby mode. This is fine. It means that the standby instance is ready to take over if the primary instance goes down.

The standby instance will initialize and will try to take a lock on wal_dir, but will fail because the primary instance has made a lock on wal_dir. So the standby instance goes into a loop, reading the write ahead log which the primary instance is writing (so the two instances are always in sync), and trying to take the lock. If the primary instance goes down for any reason, the lock will be released. In this case, the standby instance will succeed in taking the lock, will connect on the listen address and will become the primary instance. Expect to see a notification ending with the words I> ready to accept requests.

Thus there is no noticeable downtime if the primary instance goes down.

Hot standby feature has no effect:

• if wal_dir_rescan_delay = a large number (on Mac OS and FreeBSD); on these platforms, it is designed so that the loop repeats every wal_dir_rescan_delay seconds.
• if wal_mode = ‘none’; it is designed to work with wal_mode = 'write' or wal_mode = 'fsync'.
• for spaces created with engine = ‘vinyl’; it is designed to work for spaces created with engine = 'memtx'.

Type: boolean

Default: false

Environment variable: TT_HOT_STANDBY

Dynamic: no

Replication

• replication
• replication_anon
• bootstrap_strategy
• replication_connect_timeout
• replication_connect_quorum
• replication_skip_conflict
• replication_sync_lag
• replication_sync_timeout
• replication_timeout
• replicaset_uuid
• instance_uuid
• replication_synchro_quorum
• replication_synchro_timeout
• replication_threads
• election_mode
• election_timeout
• election_fencing_mode

replication¶

Since version 1.7.4. If replication is not an empty string, the instance is considered to be a Tarantool replica. The replica will try to connect to the master specified in replication with a URI (Universal Resource Identifier), for example:

konstantin:secret_password@tarantool.org:3301

If there is more than one replication source in a replica set, specify an array of URIs, for example (replace ‘uri’ and ‘uri2’ in this example with valid URIs):

box.cfg{ replication = { 'uri1', 'uri2' } }

Note

Starting from version 2.10.0, there is a number of other ways for specifying several URIs. See syntax examples.

If one of the URIs is “self” – that is, if one of the URIs is for the instance where box.cfg{} is being executed – then it is ignored. Thus, it is possible to use the same replication specification on multiple server instances, as shown in these examples.

The default user name is ‘guest’.

A read-only replica does not accept data-change requests on the listen port.

The replication parameter is dynamic, that is, to enter master mode, simply set replication to an empty string and issue:

box.cfg{ replication = new-value }

Type: string

Default: null

Environment variable: TT_REPLICATION

Dynamic: yes

replication_anon¶

Since version 2.3.1. A Tarantool replica can be anonymous. This type of replica is read-only (but you still can write to temporary and replica-local spaces), and it isn’t present in the _cluster table.

Since an anonymous replica isn’t registered in the _cluster table, there is no limitation for anonymous replicas count in a replica set: you can have as many of them as you want.

In order to make a replica anonymous, pass the option replication_anon=true to box.cfg and set read_only to true.

Let’s go through anonymous replica bootstrap. Suppose we have got a master configured with

box.cfg{listen=3301}

and created a local space called “loc”:

box.schema.space.create('loc', {is_local=true})
box.space.loc:create_index("pk")

Now, to configure an anonymous replica, we need to issue box.cfg, as usual.

box.cfg{replication_anon=true, read_only=true, replication=3301}

As mentioned above, replication_anon may be set to true only together with read_only. The instance will fetch the master’s snapshot and start following its changes. It will receive no id, so its id value will remain zero.

tarantool> box.info.id
---
- 0
...
tarantool> box.info.replication
---
- 1:
    id: 1
    uuid: 3c84f8d9-e34d-4651-969c-3d0ed214c60f
    lsn: 4
    upstream:
    status: follow
    idle: 0.6912029999985
    peer:
    lag: 0.00014615058898926
...

Now we can use the replica. For example, we can do inserts into the local space:

tarantool> for i = 1,10 do
    > box.space.loc:insert{i}
    > end
---
...

Note that while the instance is anonymous, it will increase the 0-th component of its vclock:

tarantool> box.info.vclock
---
- {0: 10, 1: 4}
...

Let’s now promote the anonymous replica to a regular one:

tarantool> box.cfg{replication_anon=false}
2019-12-13 20:34:37.423 [71329] main I> assigned id 2 to replica 6a9c2ed2-b9e1-4c57-a0e8-51a46def7661
2019-12-13 20:34:37.424 [71329] main/102/interactive I> set 'replication_anon' configuration option to false
---
...

tarantool> 2019-12-13 20:34:37.424 [71329] main/117/applier/ I> subscribed
2019-12-13 20:34:37.424 [71329] main/117/applier/ I> remote vclock {1: 5} local vclock {0: 10, 1: 5}
2019-12-13 20:34:37.425 [71329] main/118/applierw/ C> leaving orphan mode

The replica has just received an id equal to 2. We can make it read-write now.

tarantool> box.cfg{read_only=false}
2019-12-13 20:35:46.392 [71329] main/102/interactive I> set 'read_only' configuration option to false
---
...

tarantool> box.schema.space.create('test')
---
- engine: memtx
before_replace: 'function: 0x01109f9dc8'
on_replace: 'function: 0x01109f9d90'
ck_constraint: []
field_count: 0
temporary: false
index: []
is_local: false
enabled: false
name: test
id: 513
- created
...

tarantool> box.info.vclock
---
- {0: 10, 1: 5, 2: 2}
...

Now the replica tracks its changes in the 2nd vclock component, as expected. It can also become a replication master from now on.

Notes:

• You cannot replicate from an anonymous instance.
• To promote an anonymous instance to a regular one, first start it as anonymous, and only then issue box.cfg{replication_anon=false}
• In order for the deanonymization to succeed, the instance must replicate from some read-write instance, otherwise it cannot be added to the _cluster table.

Type: boolean

Default: false

Environment variable: TT_REPLICATION_ANON

Dynamic: yes

bootstrap_strategy¶

Since 2.11.0.

Specifies a strategy used to bootstrap a replica set. The following strategies are available:

• auto: a node doesn’t boot if a half or more of other nodes in a replica set are not connected. For example, if the replication parameter contains 2 or 3 nodes, a node requires 2 connected instances. In the case of 4 or 5 nodes, at least 3 connected instances are required. Moreover, a bootstrap leader fails to boot unless every connected node has chosen it as a bootstrap leader.
• legacy (deprecated since 2.11.0): a node requires the replication_connect_quorum number of other nodes to be connected. This option is added to keep the compatibility with the current versions of Cartridge and might be removed in the future.

Type: string

Default: auto

Environment variable: TT_BOOTSTRAP_STRATEGY

Dynamic: yes

replication_connect_timeout¶

Since version 1.9.0. The number of seconds that a replica will wait when trying to connect to a master in a cluster. See orphan status for details.

This parameter is different from replication_timeout, which a master uses to disconnect a replica when the master receives no acknowledgments of heartbeat messages.

Type: float

Default: 30

Environment variable: TT_REPLICATION_CONNECT_TIMEOUT

Dynamic: yes

replication_connect_quorum¶

Deprecated since 2.11.0. This option is in effect if bootstrap_strategy is set to legacy.

Specifies the number of nodes to be up and running to start a replica set. This parameter has effect during bootstrap or configuration update. Setting replication_connect_quorum to 0 makes Tarantool require no immediate reconnect only in case of recovery. See Orphan status for details.

Example:

box.cfg { replication_connect_quorum = 2 }

Type: integer

Default: null

Environment variable: TT_REPLICATION_CONNECT_QUORUM

Dynamic: yes

replication_skip_conflict¶

Since version 1.10.1. By default, if a replica adds a unique key that another replica has added, replication stops with error = ER_TUPLE_FOUND.

However, by specifying replication_skip_conflict = true, users can state that such errors may be ignored. So instead of saving the broken transaction to the xlog, it will be written there as NOP (No operation).

Example:

box.cfg{replication_skip_conflict=true}

Type: boolean

Default: false

Environment variable: TT_REPLICATION_SKIP_CONFLICT

Dynamic: yes

Note

replication_skip_conflict = true is recommended to be used only for manual replication recovery.

replication_sync_lag¶

Since version 1.9.0. The maximum lag allowed for a replica. When a replica syncs (gets updates from a master), it may not catch up completely. The number of seconds that the replica is behind the master is called the “lag”. Syncing is considered to be complete when the replica’s lag is less than or equal to replication_sync_lag.

If a user sets replication_sync_lag to nil or to 365 * 100 * 86400 (TIMEOUT_INFINITY), then lag does not matter – the replica is always considered to be “synced”. Also, the lag is ignored (assumed to be infinite) in case the master is running Tarantool older than 1.7.7, which does not send heartbeat messages.

This parameter is ignored during bootstrap. See orphan status for details.

Type: float

Default: 10

Environment variable: TT_REPLICATION_SYNC_LAG

Dynamic: yes

replication_sync_timeout¶

Since version 1.10.2. The number of seconds that a node waits when trying to sync with other nodes in a replica set (see bootstrap_strategy), after connecting or during configuration update. This could fail indefinitely if replication_sync_lag is smaller than network latency, or if the replica cannot keep pace with master updates. If replication_sync_timeout expires, the replica enters orphan status.

Type: float

Default: 300

Environment variable: TT_REPLICATION_SYNC_TIMEOUT

Dynamic: yes

Note

The default replication_sync_timeout value is going to be changed in future versions from 300 to 0. You can learn the reasoning behind this decision from the Default value for replication_sync_timeout topic, which also describes how to try the new behavior in the current version.

replication_timeout¶

Since version 1.7.5. If the master has no updates to send to the replicas, it sends heartbeat messages every replication_timeout seconds, and each replica sends an ACK packet back.

Both master and replicas are programmed to drop the connection if they get no response in four replication_timeout periods. If the connection is dropped, a replica tries to reconnect to the master.

See more in Monitoring a replica set.

Type: integer

Default: 1

Environment variable: TT_REPLICATION_TIMEOUT

Dynamic: yes

replicaset_uuid¶

Since version 1.9.0. As described in section “Replication architecture”, each replica set is identified by a universally unique identifier called replica set UUID, and each instance is identified by an instance UUID.

Ordinarily it is sufficient to let the system generate and format the UUID strings which will be permanently stored.

However, some administrators may prefer to store Tarantool configuration information in a central repository, for example Apache ZooKeeper. Such administrators can assign their own UUID values for either – or both – instances (instance_uuid) and replica set (replicaset_uuid), when starting up for the first time.

General rules:

• The values must be true unique identifiers, not shared by other instances or replica sets within the common infrastructure.
• The values must be used consistently, not changed after initial setup (the initial values are stored in snapshot files and are checked whenever the system is restarted).
• The values must comply with RFC 4122. The nil UUID is not allowed.

The UUID format includes sixteen octets represented as 32 hexadecimal (base 16) digits, displayed in five groups separated by hyphens, in the form 8-4-4-4-12 for a total of 36 characters (32 alphanumeric characters and four hyphens).

Example:

box.cfg{replicaset_uuid='7b853d13-508b-4b8e-82e6-806f088ea6e9'}

Type: string

Default: null

Environment variable: TT_REPLICASET_UUID

Dynamic: no

instance_uuid¶

Since version 1.9.0. For replication administration purposes, it is possible to set the universally unique identifiers of the instance (instance_uuid) and the replica set (replicaset_uuid), instead of having the system generate the values.

See the description of replicaset_uuid parameter for details.

Example:

box.cfg{instance_uuid='037fec43-18a9-4e12-a684-a42b716fcd02'}

Type: string

Default: null

Environment variable: TT_INSTANCE_UUID

Dynamic: no

replication_synchro_quorum¶

Since version 2.5.1. For synchronous replication only. This option tells how many replicas should confirm the receipt of a synchronous transaction before it can finish its commit.

Since version 2.5.3, the option supports dynamic evaluation of the quorum number. That is, the number of quorum can be specified not as a constant number, but as a function instead. In this case, the option returns the formula evaluated. The result is treated as an integer number. Once any replicas are added or removed, the expression is re-evaluated automatically.

For example,

box.cfg{replication_synchro_quorum = "N / 2 + 1"}

Where N is a current number of registered replicas in a cluster.

Keep in mind that the example above represents a canonical quorum definition. The formula at least 50% of the cluster size + 1 guarantees data reliability. Using a value less than the canonical one might lead to unexpected results, including a split-brain.

Since version 2.10.0, this option does not account for anonymous replicas.

The default value for this parameter is N / 2 + 1.

It is not used on replicas, so if the master dies, the pending synchronous transactions will be kept waiting on the replicas until a new master is elected.

If the value for this option is set to 1, the synchronous transactions work like asynchronous when not configured. 1 means that successful WAL write to the master is enough to commit.

Type: number

Default: N / 2 + 1 (before version 2.10.0, the default value was 1)

Environment variable: TT_REPLICATION_SYNCHRO_QUORUM

Dynamic: yes

replication_synchro_timeout¶

Since version 2.5.1. For synchronous replication only. Tells how many seconds to wait for a synchronous transaction quorum replication until it is declared failed and is rolled back.

It is not used on replicas, so if the master dies, the pending synchronous transactions will be kept waiting on the replicas until a new master is elected.

Type: number

Default: 5

Environment variable: TT_REPLICATION_SYNCHRO_TIMEOUT

Dynamic: yes

replication_threads¶

Since version 2.10.0. The number of threads spawned to decode the incoming replication data.

The default value is 1. It means that a single separate thread handles all the incoming replication streams. In most cases, one thread is enough for all incoming data. Therefore, it is likely that the user will not need to set this configuration option.

Possible values range from 1 to 1000. If there are multiple replication threads, connections to serve are distributed evenly between the threads.

Type: number

Default: 1

Possible values: from 1 to 1000

Environment variable: TT_REPLICATION_THREADS

Dynamic: no

election_mode¶

Since version 2.6.1. Specifies the role of a replica set node in the leader election process.

Possible values:

• off
• voter
• candidate
• manual.

Participation of a replica set node in the automated leader election can be turned on and off by this option.

The default value is off. All nodes that have values other than off run the Raft state machine internally talking to other nodes according to the Raft leader election protocol. When the option is off, the node accepts Raft messages from other nodes, but it doesn’t participate in the election activities, and this doesn’t affect the node’s state. So, for example, if a node is not a leader but it has election_mode = 'off', it is writable anyway.

You can control which nodes can become a leader. If you want a node to participate in the election process but don’t want that it becomes a leaders, set the election_mode option to voter. In this case, the election works as usual, this particular node will vote for other nodes, but won’t become a leader.

If the node should be able to become a leader, use election_mode = 'candidate'.

Since version 2.8.2, the manual election mode is introduced. It may be used when a user wants to control which instance is the leader explicitly instead of relying on the Raft election algorithm.

When an instance is configured with the election_mode='manual', it behaves as follows:

• By default, the instance acts like a voter – it is read-only and may vote for other instances that are candidates.
• Once box.ctl.promote() is called, the instance becomes a candidate and starts a new election round. If the instance wins the elections, it becomes a leader, but won’t participate in any new elections.

Type: string

Default: ‘off’

Environment variable: TT_ELECTION_MODE

Dynamic: yes

election_timeout¶

Since version 2.6.1. Specifies the timeout between election rounds in the leader election process if the previous round ended up with a split-vote.

In the leader election process, there can be an election timeout for the case of a split-vote. The timeout can be configured using this option; the default value is 5 seconds.

It is quite big, and for most of the cases it can be freely lowered to 300-400 ms. It can be a floating point value (300 ms would be box.cfg{election_timeout = 0.3}).

To avoid the split vote repeat, the timeout is randomized on each node during every new election, from 100% to 110% of the original timeout value. For example, if the timeout is 300 ms and there are 3 nodes started the election simultaneously in the same term, they can set their election timeouts to 300, 310, and 320 respectively, or to 305, 302, and 324, and so on. In that way, the votes will never be split because the election on different nodes won’t be restarted simultaneously.

Type: number

Default: 5

Environment variable: TT_ELECTION_TIMEOUT

Dynamic: yes

election_fencing_mode¶

Since version 2.11.0. In earlier Tarantool versions, use election_fencing_enabled instead.

Specifies the leader fencing mode that affects the leader election process. When the parameter is set to soft or strict, the leader resigns its leadership if it has less than replication_synchro_quorum of alive connections to the cluster nodes. The resigning leader receives the status of a follower in the current election term and becomes read-only.

• In soft mode, a connection is considered dead if there are no responses for 4*replication_timeout seconds both on the current leader and the followers.
• In strict mode, a connection is considered dead if there are no responses for 2*replication_timeout seconds on the current leader and 4*replication_timeout seconds on the followers. This improves chances that there is only one leader at any time.

Fencing applies to the instances that have the election_mode set to candidate or manual. To turn off leader fencing, set election_fencing_mode to off.

Type: string

Default: ‘soft’

Environment variable: TT_ELECTION_FENCING_MODE

Dynamic: yes

Networking

• io_collect_interval
• net_msg_max
• readahead
• iproto_threads

io_collect_interval¶

Since version 1.4.9. The instance will sleep for io_collect_interval seconds between iterations of the event loop. Can be used to reduce CPU load in deployments in which the number of client connections is large, but requests are not so frequent (for example, each connection issues just a handful of requests per second).

Type: float

Default: null

Environment variable: TT_IO_COLLECT_INTERVAL

Dynamic: yes

net_msg_max¶

Since version 1.10.1. To handle messages, Tarantool allocates fibers. To prevent fiber overhead from affecting the whole system, Tarantool restricts how many messages the fibers handle, so that some pending requests are blocked.

On powerful systems, increase net_msg_max and the scheduler will immediately start processing pending requests.

On weaker systems, decrease net_msg_max and the overhead may decrease although this may take some time because the scheduler must wait until already-running requests finish.

When net_msg_max is reached, Tarantool suspends processing of incoming packages until it has processed earlier messages. This is not a direct restriction of the number of fibers that handle network messages, rather it is a system-wide restriction of channel bandwidth. This in turn causes restriction of the number of incoming network messages that the transaction processor thread handles, and therefore indirectly affects the fibers that handle network messages. (The number of fibers is smaller than the number of messages because messages can be released as soon as they are delivered, while incoming requests might not be processed until some time after delivery.)

On typical systems, the default value (768) is correct.

Type: integer

Default: 768

Environment variable: TT_NET_MSG_MAX

Dynamic: yes

readahead¶

Since version 1.6.2. The size of the read-ahead buffer associated with a client connection. The larger the buffer, the more memory an active connection consumes and the more requests can be read from the operating system buffer in a single system call. The rule of thumb is to make sure the buffer can contain at least a few dozen requests. Therefore, if a typical tuple in a request is large, e.g. a few kilobytes or even megabytes, the read-ahead buffer size should be increased. If batched request processing is not used, it’s prudent to leave this setting at its default.

Type: integer

Default: 16320

Environment variable: TT_READAHEAD

Dynamic: yes

iproto_threads¶

Since version 2.8.1. The number of network threads. There can be unusual workloads where the network thread is 100% loaded and the transaction processor thread is not, so the network thread is a bottleneck. In that case set iproto_threads to 2 or more. The operating system kernel will determine which connection goes to which thread.

On typical systems, the default value (1) is correct.

Type: integer

Default: 1

Environment variable: TT_IPROTO_THREADS

Dynamic: no

Logging

This section provides information on how to configure options related to logging. You can also use the log module to configure logging in your application.

• log_level
• log
• log_nonblock
• too_long_threshold
• log_format
• log_modules

log_level¶

Since version 1.6.2. Specifies the level of detail the log has. There are seven levels:

• 1 – SYSERROR
• 2 – ERROR
• 3 – CRITICAL
• 4 – WARNING
• 5 – INFO
• 6 – VERBOSE
• 7 – DEBUG

By setting log_level, you can enable logging of all events with severities above or equal to the given level. Tarantool prints logs to the standard error stream by default. This can be changed with the log configuration parameter.

Type: integer

Default: 5

Environment variable: TT_LOG_LEVEL

Dynamic: yes

Note

Prior to Tarantool 1.7.5 there were only six levels and DEBUG was level 6. Starting with Tarantool 1.7.5, VERBOSE is level 6 and DEBUG is level 7. VERBOSE is a new level for monitoring repetitive events which would cause too much log writing if INFO were used instead.

log¶

Since version 1.7.4. By default, Tarantool sends the log to the standard error stream (stderr). If log is specified, Tarantool can send the log to a:

• file
• pipe
• system logger

Example 1: sending the log to the tarantool.log file.

box.cfg{log = 'tarantool.log'}
-- or
box.cfg{log = 'file:tarantool.log'}

This opens the file tarantool.log for output on the server’s default directory. If the log string has no prefix or has the prefix “file:”, then the string is interpreted as a file path.

Example 2: sending the log to a pipe.

box.cfg{log = '| cronolog tarantool.log'}
-- or
box.cfg{log = 'pipe: cronolog tarantool.log'}

This starts the program cronolog when the server starts, and sends all log messages to the standard input (stdin) of cronolog. If the log string begins with ‘|’ or has the prefix “pipe:”, then the string is interpreted as a Unix pipeline.

Example 3: sending the log to syslog.

box.cfg{log = 'syslog:identity=tarantool'}
-- or
box.cfg{log = 'syslog:facility=user'}
-- or
box.cfg{log = 'syslog:identity=tarantool,facility=user'}
-- or
box.cfg{log = 'syslog:server=unix:/dev/log'}

If the log string begins with “syslog:”, then it is interpreted as a message for the syslogd program, which normally is running in the background on any Unix-like platform. The setting can be syslog:, syslog:facility=..., syslog:identity=..., syslog:server=..., or a combination.

• The syslog:identity setting is an arbitrary string, which is placed at the beginning of all messages. The default value is “tarantool”.
• The syslog:facility setting is currently ignored but will be used in the future. The value must be one of the syslog keywords, which tell syslogd where the message should go. The possible values are: auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, security, syslog, user, uucp, local0, local1, local2, local3, local4, local5, local6, local7. The default value is: local7.
• The syslog:server setting is the locator for the syslog server. It can be a Unix socket path beginning with “unix:”, or an ipv4 port number. The default socket value is: dev/log (on Linux) or /var/run/syslog (on macOS). The default port value is: 514, the UDP port.

When logging to a file, Tarantool reopens the log on SIGHUP. When log is a program, its PID is saved in the log.pid variable. You need to send it a signal to rotate logs.

Type: string

Default: null

Environment variable: TT_LOG

Dynamic: no

log_nonblock¶

Since version 1.7.4. If log_nonblock equals true, Tarantool does not block during logging when the system is not ready for writing, and drops the message instead. If log_level is high, and many messages go to the log, setting log_nonblock to true may improve logging performance at the cost of some log messages getting lost.

This parameter has effect only if log is configured to send logs to a pipe or system logger. The default log_nonblock value is nil, which means that blocking behavior corresponds to the logger type:

• false for stderr and file loggers.
• true for a pipe and system logger.

This is a behavior change: in earlier versions of the Tarantool server, the default value was true.

Type: boolean

Default: nil

Environment variable: TT_LOG_NONBLOCK

Dynamic: no

too_long_threshold¶

Since version 1.6.2. If processing a request takes longer than the given value (in seconds), warn about it in the log. Has effect only if log_level is greater than or equal to 4 (WARNING).

Type: float

Default: 0.5

Environment variable: TT_TOO_LONG_THRESHOLD

Dynamic: yes

log_format¶

Since version 1.7.6. Log entries have two possible formats:

• ‘plain’ (the default), or
• ‘json’ (with more detail and with JSON labels).

Here is what a log entry looks like if box.cfg{log_format='plain'}:

2017-10-16 11:36:01.508 [18081] main/101/interactive I> set 'log_format' configuration option to "plain"

Here is what a log entry looks like if box.cfg{log_format='json'}:

{"time": "2017-10-16T11:36:17.996-0600",
"level": "INFO",
"message": "set 'log_format' configuration option to \"json\"",
"pid": 18081,|
"cord_name": "main",
"fiber_id": 101,
"fiber_name": "interactive",
"file": "builtin\/box\/load_cfg.lua",
"line": 317}

The log_format='plain' entry has a time value, process ID, cord name, fiber_id, fiber_name, log level, and message.

The log_format='json' entry has the same fields along with their labels, and in addition has the file name and line number of the Tarantool source.

Type: string

Default: ‘plain’

Environment variable: TT_LOG_FORMAT

Dynamic: yes

log_modules¶

Since version 2.11.0. Configure the specified log levels (log_level) for different modules.

You can specify a logging level for the following module types:

• Modules (files) that use the default logger. Example: Set log levels for files that use the default logger.
• Modules that use custom loggers created using the log.new() function. Example: Set log levels for modules that use custom loggers.
• The tarantool module that enables you to configure the logging level for Tarantool core messages. Specifically, it configures the logging level for messages logged from non-Lua code, including C modules. Example: Set a log level for C modules.

Type: table

Default: blank

Environment variable: TT_LOG_MODULES

Dynamic: yes

Example 1: Set log levels for files that use the default logger

Suppose you have two identical modules placed by the following paths: test/logging/module1.lua and test/logging/module2.lua. These modules use the default logger and look as follows:

return {
    say_hello = function()
        local log = require('log')
        log.info('Info message from module1')
    end
}

To load these modules in your application, you need to add the corresponding require directives:

module1 = require('test.logging.module1')
module2 = require('test.logging.module2')

To configure logging levels, you need to provide module names corresponding to paths to these modules. In the example below, the box_cfg variable contains logging settings that can be passed to the box.cfg() function:

box_cfg = { log_modules = {
    ['test.logging.module1'] = 'verbose',
    ['test.logging.module2'] = 'error' }
}

Given that module1 has the verbose logging level and module2 has the error level, calling module1.say_hello() shows a message but module2.say_hello() is swallowed:

-- Prints 'info' messages --
module1.say_hello()
--[[
[92617] main/103/interactive/test.logging.module1 I> Info message from module1
---
...
--]]

-- Swallows 'info' messages --
module2.say_hello()
--[[
---
...
--]]

Example 2: Set log levels for modules that use custom loggers

In the example below, the box_cfg variable contains logging settings that can be passed to the box.cfg() function. This example shows how to set the verbose level for module1 and the error level for module2:

box_cfg = { log_level = 'warn',
            log_modules = {
                module1 = 'verbose',
                module2 = 'error' }
}

To create custom loggers, call the log.new() function:

-- Creates new loggers --
module1_log = require('log').new('module1')
module2_log = require('log').new('module2')

Given that module1 has the verbose logging level and module2 has the error level, calling module1_log.info() shows a message but module2_log.info() is swallowed:

-- Prints 'info' messages --
module1_log.info('Info message from module1')
--[[
[16300] main/103/interactive/module1 I> Info message from module1
---
...
--]]

-- Swallows 'debug' messages --
module1_log.debug('Debug message from module1')
--[[
---
...
--]]

-- Swallows 'info' messages --
module2_log.info('Info message from module2')
--[[
---
...
--]]

Example 3: Set a log level for C modules

In the example below, the box_cfg variable contains logging settings that can be passed to the box.cfg() function. This example shows how to set the info level for the tarantool module:

box_cfg = { log_level = 'warn',
            log_modules = { tarantool = 'info' } }

The specified level affects messages logged from C modules:

ffi = require('ffi')

-- Prints 'info' messages --
ffi.C._say(ffi.C.S_INFO, nil, 0, nil, 'Info message from C module')
--[[
[6024] main/103/interactive I> Info message from C module
---
...
--]]

-- Swallows 'debug' messages --
ffi.C._say(ffi.C.S_DEBUG, nil, 0, nil, 'Debug message from C module')
--[[
---
...
--]]

The example above uses the LuaJIT ffi library to call C functions provided by the say module.

Feedback

• feedback_enabled
• feedback_host
• feedback_interval

By default, a Tarantool daemon sends a small packet once per hour, to https://feedback.tarantool.io. The packet contains three values from box.info: box.info.version, box.info.uuid, and box.info.cluster_uuid. By changing the feedback configuration parameters, users can adjust or turn off this feature.

feedback_enabled¶

Since version 1.10.1. Whether to send feedback.

If this is set to true, feedback will be sent as described above. If this is set to false, no feedback will be sent.

Type: boolean

Default: true

Environment variable: TT_FEEDBACK_ENABLED

Dynamic: yes

feedback_host¶

Since version 1.10.1. The address to which the packet is sent. Usually the recipient is Tarantool, but it can be any URL.

Type: string

Default: https://feedback.tarantool.io

Environment variable: TT_FEEDBACK_HOST

Dynamic: yes

feedback_interval¶

Since version 1.10.1. The number of seconds between sendings, usually 3600 (1 hour).

Type: float

Default: 3600

Environment variable: TT_FEEDBACK_INTERVAL

Dynamic: yes

Deprecated parameters

These parameters are deprecated since Tarantool version 1.7.4:

• coredump
• logger
• logger_nonblock
• panic_on_snap_error,
• panic_on_wal_error
• replication_source
• slab_alloc_arena
• slab_alloc_maximal
• slab_alloc_minimal
• snap_dir
• snapshot_count
• snapshot_period
• rows_per_wal
• election_fencing_enabled

coredump¶

Deprecated, do not use.

Type: boolean

Default: false

Dynamic: no

logger¶

Deprecated in favor of log. The parameter was only renamed, while the type, values and semantics remained intact.

logger_nonblock¶

Deprecated in favor of log_nonblock. The parameter was only renamed, while the type, values and semantics remained intact.

panic_on_snap_error¶

Deprecated in favor of force_recovery.

If there is an error while reading a snapshot file (at server instance start), abort.

Type: boolean

Default: true

Dynamic: no

panic_on_wal_error¶

Deprecated in favor of force_recovery.

Type: boolean

Default: true

Dynamic: yes

replication_source¶

Deprecated in favor of replication. The parameter was only renamed, while the type, values and semantics remained intact.

slab_alloc_arena¶

Deprecated in favor of memtx_memory.

How much memory Tarantool allocates to actually store tuples, in gigabytes. When the limit is reached, INSERT or UPDATE requests begin failing with error ER_MEMORY_ISSUE. While the server does not go beyond the defined limit to allocate tuples, there is additional memory used to store indexes and connection information. Depending on actual configuration and workload, Tarantool can consume up to 20% more than the limit set here.

Type: float

Default: 1.0

Dynamic: no

slab_alloc_maximal¶

Deprecated in favor of memtx_max_tuple_size. The parameter was only renamed, while the type, values and semantics remained intact.

slab_alloc_minimal¶

Deprecated in favor of memtx_min_tuple_size. The parameter was only renamed, while the type, values and semantics remained intact.

snap_dir¶

Deprecated in favor of memtx_dir. The parameter was only renamed, while the type, values and semantics remained intact.

snapshot_period¶

Deprecated in favor of checkpoint_interval. The parameter was only renamed, while the type, values and semantics remained intact.

snapshot_count¶

Deprecated in favor of checkpoint_count. The parameter was only renamed, while the type, values and semantics remained intact.

rows_per_wal¶

Deprecated in favor of wal_max_size. The parameter does not allow to properly limit size of WAL logs.

election_fencing_enabled¶

Deprecated in Tarantool v2.11 in favor of election_fencing_mode.

The parameter does not allow using the strict fencing mode. Setting to true is equivalent to setting the soft election_fencing_mode. Setting to false is equivalent to setting the off election_fencing_mode.

Type: boolean

Default: true

Environment variable: TT_ELECTION_FENCING_ENABLED

Dynamic: yes